Subject: RE: Electronic AP for DLSw Multicast Spec

From: Stephane St-Hilaire <[email-masked]>
Date: Mon, 26 Aug 96 11:42:00 PDT

Hi,

I have some reservations about the proposed spec, the only thing that I'm   
not really crazy about is in regards to the Vendor Specific UDP Packets   
section (even though I assume this is not really UDP specific ? But   
really a section on vendor specific frames since when already having a   
TCP connection with a partner these frames would probably be sent on TCP   
???...)

The use of the Version number field which would become a (most of the   
time version number field or sometimes a packet type field) is a bit   
awkward to say the least and complicates things unneccessarly. There's   
already a standard message type field (actually 2 of these for control   
frames in the current SSP header) and I don't see why we couldn't use   
this already existing field. All that would be needed is to define a   
standard "VENDOR_SPECIFIC" SSP message type and keep the existing header   
intact. There's already 2 bytes reserved at offset 12 of the SSP header   
that is not used all we need is one more byte to put the OUI in.
Beyond the standard SSP header you could then have the actual vendor   
specific stuff.

I also don't see why AIW standard messages would need to be packaged in   
"Vendor specific" messages with a OUI of zeros... I mean if the AIW sees   
some form of messages useful enough to become "standards" then they   
should just assign standard SSP message types ?, seems logical enough.

Also with the documented format there's no standardized location for a   
message length field, and it is probably needed (unless the documented   
header length field is really a packet length field and if so one byte is   
probably insufficient),
Most vendors will probably assign a location for such a thing anyways and   
there's no point in making that a vendor specific thing ? Considering   
that a vendor may send by mistake (mistakes happen...) a vendor specific   
frame to a partner which didn't match the capability it the CAPEX   
exchange, there's no way for the receiving partner to disgard this frame   
with the current header so the only thing left to do is the close the   
connection which is against the philosophy outlined in the packet   
handling section.

If we are to keep most to the newly  defined header for vendor specific   
frames intact I suggest using a value other than 0x32 as the packet type   
(since this is really a value of 2 (ASCII)  and the next logical version   
number of DLSw that could be used for many other things in the "near"   
future, vs  a "packet type identifier", May be a value of 0x00 or 0xFF is   
better ? And add a message length field to the header (or document the   
header length field as a packet lenght field of 2 bytes).

Phrasing wise (ok that's not necessarly such a big deal), the second   
sentence of the Vendor specific UDP packets section goes on as: "It   
matches the current SSP packet header with two notable exceptions:" To be   
honest it really doesn't match the current SSP header in anyway. I'd   
rather see something like "It doesn't match the current SSP packet header   
at all with one notable exception; the header length field which is the   
only that retains its location and meaning ; )"

Ok so that's it for my comments, the real important issue I hope the AIW   
will be tackling soon is the issue of discovering DLSw capable routers,   
to reduce the admnistration headaches.

Regards
Steph

 ----------
From:  aiw-dlsw-scalability
Sent:  Friday, August 23, 1996 8:21 PM
To:  stephanh
Subject:  Electronic AP for DLSw Multicast Spec

Folks -

Sorry about the delay in getting this out... some hand-off problems and
excessive travel problems.   Anyway, here's an updated copy of the DLSw
Multicast Spec from AIW 11.    Please post all comments to this forum.   
 If we
receive no significant objections b 9/13/96, we will declare the
specification
to be AP.     I'll post a Microsoft Word version of the document early   
next
week and let ya all know where it is.

Cheers,
Dave

David Bryant 3Com Corp        October 1995
Mike Redden  Proteon Inc        Revised 7/96
Paul Britton  Data Connection Ltd.

A submission to the APPN Implementers Workshop
Draft Proposal for Approved Pages Status
at
AIW 11
July 1996, NC

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 26 Aug 96 22:40:36 EDT

Stephane - responses below in CAPS

To: aiw-siglets-dlsw-redist  @ 3mail.3com.com @ UGATE
cc:  
From: stephanh @ eicon.com (Stephane St-Hilaire) @ UGATE    
Date: Monday  August 26, 1996 11:51 AM
Subject: RE: Electronic AP for DLSw Multicast Spec
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hi,

ACTUALLY, THIS IS VERY UDP SPECIFIC.  THIS PARTICULAR FRAME FORMAT WAS REQUIRED 
BECAUSE WITH UDP COMMUNICATIONS THERE IS NO PRIOR TCP CAPEX TO DETERMINE THE 
SUPPORT LEVEL AND CONTEXT OF RECEIVED MESSAGES.  THE ONLY CAVEAT IS THAT THESE 
TYPES OF FRAMES COULD BE RECEIVED OVER TCP, DUE TO THE SECTION THAT ALLOWS 
THESE FRAMES TO BE SENT OVER TCP AS WELL. 

THIS ISSUE WAS DISCUSSED AT LENGTH TWICE AT THE AIW.  BOTH TIMES, WE REACHED 
THE SAME CONCLUSION.  THE VERSION NUMBER FIELD FOR ALL ITS INTENDED PURPOSE IS 
NOT PROVING USEABLE.  FOR EXAMPLE, IF A DLSW SENDS A VERSION 3 PACKET DOES THAT 
MEAN ALL PACKETS ARE VERSION 3?  WHAT IF YOU SEND AN SSP PACKET THAT IS DEFINED 
IN VERSION 1.  SHOULD IT SAY VERSION 1 OR VERSION 3? MORE IMPORTANTLY, REMEMBER 
THAT THIS IS DESIGNED FOR UDP TRANSPORT AND NOT TCP TRANSPORT.  THERE DOESN'T 
SEEM TO BE ANY NEED TO MANDATE THE ENTIRE SSP HEADER PARTICULARLY WHEN IT MAY 
NOT APPLY TO VENDOR SPECIFIC ENHANCEMENTS.  THE ATTENDEES OF THE AIW HAVE 
ALREADY CLOSED ON THIS ISSUE, SO UNLESS I HEAR OVERWHELMING SUPPORT FOR YOUR 
CONCERN, I WILL CONSIDER CONCENSUS REACHED AND THE MATTER CLOSED. 

THE DECISION WAS MADE TO USE AN OUI OF ZEROS TO REPRESENT AIW PACKETS SO THAT 
IMPLEMENTATIONS WOULD NOT HAVE TO ENCODE TWO PARSING RULES.  THIS WAY, PARSERS 
CAN BE CODED TO EXPECT THE OUI FIELD AND SNIFFERS CAN SIMPLY RECOGNIZE ZEROS AS 
REFLECTING A STANDARD.  ONCE AGAIN, THIS WAS AGREED TO BY THE ATTENDEES OF THE 
AIW.  SO UNLESS I HEAR OVERWHELMING SUPPORT FOR YOUR CONCERNS, I WILL READ 
CONCENSUS ON THE DOCUMENT AS IT CURRENTLY READS. 

AGAIN, THESE PACKETS HAVE NOTHING TO DO WITH TCP CONNECTIONS AND RECEIPT OF 
INVALID PACKETS IS TO BE IGNORED.  THIS IS SPECIFIED IN BOTH RFC1795 AND THIS 
ENHANCEMENT.  CAPEX EXCHANGE HAS VERY LITTLE TO DO WITH THE UDP BASED FRAMES.   
I'VE HEARD NO NEED FOR A PACKET LENGTH FROM ANY OF THE AIW ATTENDEES.  IF 
VENDOR SPECIFIC ENHANCEMENTS REQUIRE SUCH, THE VENDOR IS FREE TO PLACE SUCH A 
FIELD IN THE FRAME FOLLOWING THE MANDITORY HEADER SECTIONS. 

THE ATTENDEES OF THE AIW DID NOT SEEM TO SHARE YOUR CONCERNS.  SEE THE COMMENTS 
ABOVE.

AGREED WITH YOUR CONCERN.  FOR A MINOR CORRECTION OF THIS TYPE, I SUGGEST WE 
AMMEND IT IN THE CP VERSION OF THE DOCUMENT. 

I BELEIVE PERHAPS YOU HAVE NOT BEEN FOLLOWING THIS ACTIVITY VERY CLOSELY AS THE 
DLSW MULTICAST SPECIFICATION PROVIDES A MEANS TO ADDRESS THE AUTOMATIC 
DISCOVERY OF DLSW CAPABLE ROUTERS... THIS WAS ONE OF THE MAIN GOALS.  
Regards
Steph

 ----------

Folks -

Cheers,
Dave

---

From: Stephane St-Hilaire <[email-masked]>
Date: Tue, 27 Aug 96 14:45:00 PDT

Hi,
Responses below (not in CAPS)

>> THE ONLY CAVEAT IS THAT
>> THESE TYPES OF FRAMES COULD BE RECEIVED OVER TCP, DUE TO THE SECTION   
THAT ALLOWS
>> THESE FRAMES TO BE SENT OVER TCP AS WELL.

Ok so we agree that these frames can be sent on TCP as well.

>> FIELD IN THE FRAME FOLLOWING THE MANDITORY HEADER SECTIONS.

Well if you get such a frame on a TCP connection and want to IGNORE it,   
how do you get rid of it from the stream if you don't know it's length or   
where this length field is located ?

>> I'VE HEARD NO NEED FOR A PACKET LENGTH FROM ANY OF THE AIW ATTENDEES.
You have now.

>> THE SAME CONCLUSION.  THE VERSION NUMBER FIELD FOR ALL ITS INTENDED   
PURPOSE
>> IS NOT PROVING USEABLE.  FOR EXAMPLE, IF A DLSW SENDS A VERSION 3   
PACKET DOES THAT
>> MEAN ALL PACKETS ARE VERSION 3?  WHAT IF YOU SEND AN SSP PACKET THAT   
IS
>> DEFINED

It's obviously a waste to send a version number field on every SSP   
message since, this DLSw "revision" supported by a router is a constant,   
but still this field managed to be "approved" in 2 RFCs. On the other   
end, this "unusable" field made it possible for some vendors to be   
compatible with both DLSw RFCs, so it did serve some purpose after all. I   
would have liked it to retain its meaning but so be it since this is   
really a new header type and doesn't have much to do with current SSP   
formats. it's not a big deal.

AGREED WITH YOUR CONCERN.  FOR A MINOR CORRECTION OF THIS TYPE, I SUGGEST   
WE
AMMEND IT IN THE CP VERSION OF THE DOCUMENT.

OK.

I BELEIVE PERHAPS YOU HAVE NOT BEEN FOLLOWING THIS ACTIVITY VERY CLOSELY
Perhaps your "beliefs" are not relevant.

 AS THE DLSW MULTICAST SPECIFICATION PROVIDES A MEANS TO ADDRESS THE   
AUTOMATIC
DISCOVERY OF DLSW CAPABLE ROUTERS... THIS WAS ONE OF THE MAIN GOALS.

Allright then how does a DLSw router discover dynamically other DLSw   
routers without any configuration of their IP addresses on any end ? What   
type of SSP message would you send to discover existing DLSw routers on   
the network ? I obviously missed that section (meaculpa) . If this is   
possible and doable with this spec then I'd sincerly like to know how.

Regards
Steph

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 10 Sep 96 10:42:02 EDT

Rather than try to include the dialogue up to this point,  I think Stephane has 
one main concern at this point.  (Please correct me if I'm wrong).  Stephane 
points out that the vendor specific frame will need a length field.  This is 
necessary so that (non-vendor specific) receivers can extract (and ignore) the 
frame from a TCP stream. 

Although it is possible to require a capex exchange to validate these frame 
before sending, I think it's totally appropriate to include a message length 
within the vendor specific frames.   I, therefore, propose that we ammend the 
vendor specific frame format to read as attached at the end of this email. 

As a matter of procedure, I would recommend that we grant AP status to the 
document as it reads and ensure that correct this 
error prior to granting Closed Pages.  Alternatively, we could change the 
document and redistribute.

Would all DLSw Scalability participants please post their comments regarding AP 
status and this particular issue prior to the 
9/15 deadline for electronic AP?

Thanks to all and Stephane in particular!

-Dave

Vendor Specific UDP Packets

In order to accomodate the addition of vendor specific functions over UDP 
transport, a new SSP packet header has been defined.  This new message has the 
following important characteristics:

1) The Version Number field is set to x32 (ASCII 2) and now represents a packet 
type more than a DLSw version number.  More precisely, it is permitted and 
expected that DLSw may send packets of both types. 

2) The message length field is followed by a new 3 byte field that contains the 
specific vendors IEEE Organizationally Unique Identifier (OUI).  A value of 
zeros in this field implies an AIW standard.  

3) All fields following the new OUI field are defined outside this paper.

The following section defines this new header format:

Byte Bit  Description
0     DLSw packet type, Always set to x32 

1   Message Header Length
   Note: could be other than 72

2-3   Message length 

4-6   Vendor specific OUI
The IEEE Organizationally Unique Identifier (OUI) associated with the vendor 
specific function in question.  Note: A value of zeros implies an AIW standard

7-n    Defined by the OUI owner  

----- Previous Message ---------------------------------------------------- 

Date: Tuesday  August 27, 1996 02:50 PM

Hi,

THAT ALLOWS

You have now.

PURPOSE
PACKET DOES THAT
IS

OK.

Regards
Steph